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ABSTRACT 

Data flow languages are gaining importance because 
of their inherent asynchronous view of computation. Some 
extensions to the high-level data flow language Id (Irvine 
data flow language) are proposed to increase its effective- 
ness aid expressive power. The proposed extensions are in 
accordance with the recent advances in the area of programm- 
ing language design and programming methodology. Sequent isl- 
and mixed looping constructs are proposed which alongwith the 
existing parallel looping construct aid with the proposed 
incorporation of generators provide a comprehensive and 
flexible set of looping constructs. Stream structures are 
proposed to model the arrays of streams. Their usefulness in 
the resource management to maintain a variable number of 
queues is discussed. To aid in program abstraction and to 
enable a programmer to define his own language, tailored to 
his needs, programmer defined constructs (pdcs) are incorporated 
The approach used to incorporate programmer defined constructs 
has some similarities with the well known conditional assembly 
of macros used in low level languages. Usefulness and 
implementation of some of these aspects in conventional 
languages is briefly discussed. 



CHAPTER 1 


INTRO DUCTION 


1 *1 Objective 

Dataflow languages are gaining importance because 
of their inherent asynchronous view of computation and thus 
their ability to act as a suitable semantic basis for 
parallel computation. The objective of this thesis is to 
propose some extensions to a higher-level dataflow language 
Id [AG-P783 (Irvine dataflow language) developed by the 
Dataflow Archit ecture G-roup at University of California# 
Irvine. Proposed extensions enhance the capabilities of Id 
looping constructs, provide a general model to maintain a 
large and vaniable number of queues to deal with the problems 
of resource management, and enable a programmer to define 
his own higher level constructs using available Id schemas. 
Our proposed extensions should be viewed in the context of 
the recent advances in programming language design and 
programming methodology some of which arc briefly discussed 
in Section 1.3. A reader who is familiar with the dataflow 
languages, their advantages over conventional languages, 
and Id may skip rest of this chapter and the next chapter. 
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1 * 2 Conventional languages vs dataflow languages and 
dataflow concepts 

With the speed of semiconductor devices reaching their 

limits due to electrical propagation delays, parallel 

computation has emerged as the only "basis to speed up computation 

to solve largo and complex problems. Many computer systems 

like ILLIAC IV, CDC STAR-1 00, CRAYI etc. have "been built todate 

to exploit the power of parallel computations. However, they 

* 

are still "based on conventional Von Neumann architecture 

<r 

characterized "by sequential control and memory cells, and thus 
require either complex software or hardware mechanisms to 
bring out the parallelism in the program. A new dimension is 
added to the problem by the recent advances in LSI technology. 
Largo numbers of inexpensive processors are now available 
and thus "distributed processing" among many distinct 
processors with essentially autonomous control is gaining 
favour. However, it is now widely recognized that under the 
constraints of conventional architecture and languages it is 
extremely difficult to efficiently utilize a large number of 
processors, since sequential control inhibits asynchronous 
behaviour and existence of memory potentially requires 
proper synchronization of accesses to each memory cell C Don 73, 
GIMT 74, Wen 75, SM 77, AG 77b, AG 77c etc.]'. In past many 
control primitives .for parallel computation (CALI and WAIT : 

•Xr *** r " r ' m " " rt " nr ' ,n * n " ' 1mm 

Conventional architecture and conventional languages are used 
inter chang ably as languages reflects the characteristics of 
architecture. 


in PL/l, Cobegin-coend etc.) and synchronization schemes 
( Semaphores [Dij 68] etc.) have been proposed as extensions 
to conventional languages. However, program written using 
these constructs arc limited in the degree of parallelism 
they exhibit. Thus to exploit the capabilities provided by 
recent technological advances, wo need an asynchronous view 
of computation. 

Dataflow languages have been proposed to give such 
a view of computation [Den 73, GIMT 74, AG 77b, AGP 78 etc.DThey 
are based on the observation that an operation should be execu- 
ted as soon as its input operands are available. The attract- 
iveness of dataflow schemas as the semantic basis of parallel 
computation lies in two properties: 

1 . an instruction executes when and only when all 
operands needed for that instruction become 
available , 

2. instructions at whatever level they might exist 
are purely functional in nature and produce no 
side" effect s i.e. there is no memory in conventional 
sense [AG 77b, Den 73] • 

Thus dataflow program is a set of partially ordered 
operations on operand values whero the partial ordering is 
determined solely and explicitly by the need for intermediate 
results. Dataflow languages offer several advantages 
[Den 73> KOS 73 , AG 77b, AGP 78] over conventional programming 
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languages such, as absence of variables? highly modular 
program structure and inherently functional nature. Thus 
they are well suited to describe and implement asynchronous 
behaviour required by many complex systems such as operating 
systems. Several dataflow languages and schemas [Den 73? 

EOS 73? Bah 72, KM 66 etc.] have been proposed. In 
particular dataflow language proposed by Dennis [Den 73 ] is 
well suited as a base language for a dataflow machine. Recent 
efforts have been in the direction of developing higher 
level languages so that dataflow becomes an attractive alter- 
native for the end users. Weng [ Wen 75 ] proposed a Textual 
Dataflow language which incorporates recursive schemas and 
streams. Kosinski [ Kos 73] and Bryant [Bry 77] have also 
proposed languages based on dataflow concepts. Recently 
Hankin etal [ HOS 78] have proposed a language CAJOLE which 
is still in a developmental stage. However? it allows the 
programmer to define his own new constructs. Dataflow 
Architecture group at University of California? Irvine has 
proposed a higher level dataflow language Id and a computer 
architecture suitable for its execution [ AGP 78? AG 78]. 

Id is of a more advanced nature and incorporates ideas of 
streams, monitors, nondetorministic programming, abstract 
data types and operator extensiality . In this thesis we 
will look at some of these features of Id more carefully. 
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1 .3 Programming languages in general 

In recent years production of reliable software has 
drawn a lot of attention. It has been noted that conventional 
languages are not well suited for program verification and 
for writing reliable complex software systems. Structured 
programming' has been proposed to bring order and structure in 
the otherwise chaotic world of programming languages t Bac 78], 
It is now well understood that development and maintenance of 
complex software systems is facilitated by the preservance 
of the problem structure in its solution and by modularization, 
to localize the subsequent modifications. Drive is towards 
a functional view of computation rather than a procedural 
view. Current interest in data abstraction and control 
abstraction [ LSAS 77, SW1 77] points in this direction. To 
aid the verification of programs, tho structure of looping 
constructs is being studied. It has been proposed that 
initialization of loop variables, loop terminating conditions 
and incrementation of loop variables should be explicitly 
stated and grouped to aid in program verification [ Pra 78]. 
Languages whoso semantics is more closely akin to mathematics 
have been proposed to simplify program verification 
t Gut 77, AW 77]. 

Another area which is being extensively explored, 
concerns with the linguistic aspects of the problems related 



to resource management [ JL 76] . A higher level language 
especially a language suitable for distributed processing 
should have capabilities to handle hardware and software 
resources. Hero also we see a drive towards more encapsulated 
and functional approach ( semaphores [Dij 68 ] to monitors 
[Hoa 74 ] ). 

With the Backus' proposal [Bac 78 ] a new school of 
thought is emerging in the field of programming language design. 
His main objection against the conventional programming 
languages is that they are growing ever more enoromous , but not 
stronger because of their inherent defects at the most basic 
lovol. They are founded on word - at ~ atime programming 
inherited from their ancestor Yon Neumann computer and their 
semantics is closely coupled to the state transition. They 
have more rigid parts and less variable parts because of their 
closed coupling to the state transition and dividing tho 
programming into a world of statements and world of expressions. 
Whereas, the world of expressions is orderly and has useful 
mathematical properties, tho world of statements is chaotic. 
Because of these aspects they are unable to effectively use ; 
powerful combining forms to build now programs from tho existing 
ones, and they lack useful mathematical properties. His 
proposal is to adopt a truely variable less functional program-; 
ming language which has loss rigid parts and more variable 



7 


parts. Such functional programs are often nonrepetitivc and 
nonrccursive, are hier archie ally constructed , do not name 
their arguments and donot require complex procedure declarations, 
functional programming can easily use higher level programs 
to build still higher level ones. , Since programs, their 
semantics, and their realizations are defined in the same 
language, a simple algebra of programs can be used for program 
transformations . 

We believe that some of the aspects discussed above are 
important for the next generation of programming languages which 
will be required to deal with systems of still -yet -unimagined 
complexity, 

1 .4 Overview of the thesis 

Since the thesis extensively uses the presently available 
Id constructs to describe proposed extensions, Chapter 2 briefly 
describes Id and its constructs. Block expressions, conditional' 
expressions, loop expressions, procedures, monitors, abd 
programmer defined data types are discussed. To show the use 
of some of these constructs, Id program to compute Past Fourier , 
Transform of a signal sequence Is described. 

Chapter 3 deals with sequential looping constructs, 
mixed looping constructs and generators. An alternate 
translation of for loops using for each loop and generator is 
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discussed. This view of f or loops makes the translation of 
mixed for loop constructs easy. A simplified translation of 
for each - while loop is also discussed, and, its usefulness 
in the controlled generation of the elements in a for - while 
loop and in a pdt , is shown. 

Chapter 4 describes stream structures which are useful 
in maintaining a variable and a large number of queues. Dynamic 
stream construct of Id is reviewed and some base language oper- 
ators aro extended to allow streams as creation time parameters 
for Id monitors. Usefulness of the stream structures in the 
resource management problems is shown through an example. 

Chapter 5 discusses the programmer defined constructs, 
which enable a programmer to define his own constructs and 
aids in program abstraction. Syntax for its definition and 
its use, and, its implementation is described. To bring out 
some of the relevant points and limitations several examples 
are discussed. 

In Chapter 6 we present our conclusions and observe that 
some of the concepts discussed in the thesis can also be 
incorporated in conventional languages to enhance their 
capabilities . 



CHAPTER 2 


Ids A BRIE I' INTRODUCTION 

This chapter is intended to make the reader familiar with 
the high level dataflow language Id (Irvine dataflow) together 
with the syntax and . the underlying* semantics of its constructs 
[A&P77 , AGP78] * 

ft 

2 . 1 Id and the underlying model of execution 

Id is a Block structured, expression oriented, single 
assignment language whose syntax resembles Algol-type of block 
structured language. Id provides facilities for resource 
handling via dataflow monitors incorporates data abstraction 
mechanisms (i.e. programmer defined data types), and is 
extensible • 

Id like any other dataflow language is based on the 
principle of dividing computation into smaller sub computations 
called activities which may bo executed by independent 
processing elements. Every Id program is compiled into a 
corresponding program in the base language which is an ordered 
graph consisting of operators interconnected by directed lines 
that transport values in the form of tokens. A variable in 

ft 

This section or rather this complete chapter relies heavily 
on the description of Id given in [AGP78] . 
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an Id program does not represent the name of a memory cell, 
rather it is the name of a line in the base language graph 
along which the value travels. Id variables are not typed. 

The internal representation of values is self identifying and 
thus, type is associated with a value and not a variable. A 
given variable in Id or a line in program graph is either a simple 
variable or a strea m variable [ yen 75 ] A simple variable 

carries a single token to each instance of an operator's 
execution, while a stream variable carries a linearly oi'dered 
sequence of tokens to each instance of an operator's execution. 

Id variables are strongly typed as far as streams are concerned. 
Throughout the thesis simple variables will be denoted by 
lower case letters and stream variables by upper case letters. 

Base language programs corresponding to Id programs are 
executed on a dataflow machine using Unravelling Interpreter ! 

[ AG77al . The unravelling interpreter dynamically removes 
ordering between operations due only to tine, while retaining 

| 

orderings required by the need for partial results. This 
scheme of interpretation does an automatic unfolding of loops 
and permits simultaneous execution of distinct invocations 
of the same operation. This brings out fetr more asynchrony 

I 

then what is normally possible in a dataflow language [Don 73, 

A& 7 7a ] . Underlying dataflow machine does not have memory in 
the convntional sense. The values arc carried by tokens. 
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Memory is used only to store values that arc too largo to bo 
moved efficiently; instead a pointer to stored value is carried 
by the token. Thus existence of memory is completely trans- 
parent to the Id programmer. 

2.2 Id values and basic schemas 

Id values are of nine typos; integer, real* boolean, 
string, structure, procedure definition, monitor definition, 
monitor object, and errors. First four need no explanation. 

Wo will explain structures here, rest of thou will bo treated 
in later sections. A structure value is either the empty struc- 
ture A or a set of < selector; value > ordered pairs. A 
selector is an integer, real, boolean, or string value; a value 
is any Id value. There are exactly two operators defined over 
structures — SELECT and APPEND [ AC-P78 ]. The important thing to 
note is that an append operation always creates a logically new 
structure, and the original structure may enjoy a simultaneous 
existence. Multiple selectors arc allowed. 

Wo explain three basic schemas in Id; block expression 
conditionals, and loops. 

2,2.1 Block expressions ; 

Any Id program can be written as a list of expressions. 
However, it is convenient to break a computation and identify 
certain partial results. An example of block expression is 



1 2 


x,y (x «- b * 2 + a» 
y + 2 * a 

return x + y ,y) (2.1) 

The input s to tho block expression arc those variables 
which are referenced but not assigned in tho block and outputs 
(ordered) are specified by return clause. The compilation of 
expression is shown in Figure 2.1 . An as signment st at ement 
names the line in corresponding base language graph. Id limits 
the scope of names to tho block in which they arc defined. 

Thus x,y have different values inside and outside tho block in 
expression (2.1). A const ant like 2 in Id doos not represent 
a value but function that produces that value as its output 
regardless of tho value of tho input. Box C in Figure 2.1 
represents such a function. 

2.2.2 Conditional expressions ; 

A conditional expression in Id is of tho form 

( if p(x) then f(x) olso g(x)) (2.2) 

Its base language translation is given in Figure 2.2. The ! 

i 

SWITCH operator passes tho token coming on data line to the 
T branch or the F branch depending on whether token on control 
line carries the value true or false . If any of the branch 

§ 

(T or F) is not connected and tho control input dictates that i 
branch to be taken, then the data token is simply absorbed. The; 








s 



/iipure 2,2 Compilation o f ulie oood It tonal 
e xpr e salon (2.2), 
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(£) operator merges tho two branches of conditional expression. 
A conditional expression needs all of its inputs for execution 
regardless of the branch to be taken. In a conditional 
expression tho then clause and the olse clause should contain 
equal number of expressions. Conditionals can also be written 
in the statement form. Thus expression (2.3) and expression 
(2.4) are e quivalcnt . 

( if p(x) then y f (x) ; z 1 else, y-<- g(x) ; z 0 ) (2.3) 

y,z-*-( if p(x) the n f(x), 1 else g(x), 0 ) (2.4) 

2.2.3 Loop expressions ; 

Basic loop construct in Id is a while loop (loops 
involving streams arc different) . A while loop is given in 
expression (2.5) and its compilation in Figure 2.3 

( initial i 1 ; sum ■*- 1 
while sum < s do 
new i i + 1 ; 
new sum +■ sum + i 

return sum , i ) (2.5) 

Variables initialized in the initial part and all loop 
constants such as s circulate in the loop domain. For the next 
iteration of the loop their new values arc defined by loop 
body. A default for loop constants is that their new values 
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-1 -1 

arc sane as old values. The operators 1,1 , D, D do not 

affect tlic values ox the tokens passing through them. They 
are used by the unravelling interpreter to manipulate activity 
names so that tokens belonging to different instantiations 
of a loop do not get mixed up with the tokens belonging to 
different iterations of a loop instantiation, new i is used 
to label a line which is different from i ahd does not violate 
the single assignment rule. 

Id supports many kinds of looping constructs such as 
for loops, f or ~ while loops etc. However, they are compiled in 
form of a basic while loop. Expression (2.6) gives a for - while 
loop whose equivalent while loop is given in expression (2.7)* 

( initial x f(x) 
for i from 1 to n while p(x) do 

y «• g(i) 5 
now, x ■+. f (x)+y 

return x) (2.6) 

( initial x *■ f(x) 
while i<_n A p(x) do 

y * g(i) » 

new x -t- f(x) + y^ 
new i i+1 


return x) 


(2.7) 



A "basic looping construct involving streams is given in 
expression (2,8). 

( initial s a 

for each x in X; y in Y while p(x,y) do 
new s s+x+yj 
z «-f(x,y); 

if z < t then b -t- nex t p 
else b *■ \ 

return s, all z, all b but A) (2.8) 

There are many points brought out by this expression 

which are relevant when dealing with streams. A for each 

loop operates on all the elements of a stream. Expression 

(2.8) shows a parallel looping construct in which for each 

iteration of a loop an element from X and an element from Y 

are taken, loop terminates when predicate p is satisfied, or 

either of the two streams runs out of tokens. aid, z is a 

stream producing construct and returns a stream containing 

all the values of z. but A performs what one intuitively 

expects it to do: it filters out A’s from the stream all b. 

next P construct gives next element from the stream P, when 

asked, and thus avoids circulating the streamP. next only 

has meaning when it is inside a conditional construct which is 

embedded in a loop expression. Compilation of expression (2,8) 
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is too involved and is given in Sections 4. 2. 3. 2 and 4. 2. 3. 3 
of [A&P78 ] . We will show a simpler implementation of the 
loops involving next in Chapter 4. 

2 • 3 Procedure definition and application 

A procedure definition in Id is a constant value and 
it may he created by writing; 

P procedure (x) (if x > 1 then x - 1 

else, x + 1 ) (2.9) 

x is a formal parameter y and the expression is the 
procedure body, p is the name of the line along which the 
token carrying the procedure value will travel. In Id two 
operators are defined over procedure values; 

APPLY and COMPOSE. Apply applies the procedure definition 
to a list of actual arguments. We write an application as 

res ■*- apply (p, arg ) 

where arg is actual argument. A syntactic shorthand is 
res + p (arg) 

The primitive apply is implemented as two base 

„1 

language operators; A and A as shorn in Figure 2.4. The 
A actor accepts the procedure definition and creates an 
instance of its execution. It then sends the actual 



instance of 
procedure p 
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arguments to this instance. The results of computation are 
“1 

returned to A ahd the instance of the procedure is 
automatically destroyed. Distinct instances afe created 
for the application of the same procedure at different 
places. 

Compose operator takes the input procedure value and 
"freezes" one or more of the procedure's formal parameters 
to particular actual values. For example, in 

a -procedure ( b , C ) (h * c + b / c ) ; 
d ■+■ compose < a, < 2 > > (2.10) 

d behaves as if programmer had -written 
d procedure (c) (2 * c + 2/c) 

It is possible to give a name to an Id procedure. This 
is useful in writing recursive procedures. Whenever a named 
procedure is applied its definition is also passed as an 
argument. Expression (2.11) gives a recursive procedure to 
calculate factorial function. 

y <- procedure f(n) (if n = 0 then 1 else n * f(n-1 )) 

( 2 . 11 ) 

compose and named procedures are useful in programmer 
defined data types. Procedure's arguments are not limited to 
simple variables, stream variables are also allowed. 
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* 

2.4 Dataflow monitor s 

The concept of a dataflow monito r [ A&P77, AGP78 ] 
was introduced in order to allow nondetermini stic behaviour 
generally encountered in resource management. Expression 
(2.12) assigns a dataflow monitor definition value to 
variable md. 

md + monitor (s ) 

( entry REQ do_ 

RES ■+■ ( initia l s ■*- s Q 

for e ac h req in REQ do 
new s, ans •*- f(s, req) 
return all ans 

exit RES) (2.1 2) 

Many instances of monitor objects may be created from 
this monitor definition. Creation of a monitor instance 
is done by 

me ■*" create (md,a) (2.13) 

A programmer refers to the monitor object by writing 
me. a is the initial state passed at the creation time. An. 

In [ AGP78 ] word manager is used in place of monitor. 
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instance of a monitor is not created and destroyed for only 
one invocation, but may be reused arbitrarily during its life 
span by sending to it arguments, which will be processed in 
a FIFO order. There exist only one instance of me and all 
the uses of me refers to that instance only. 

A monitor instance is shown in Figure 2.5. The entry 
operator receives all requests and forms a stream by merging 
the requests nondet erministically . This stream is passed to 
the monitor’s body. The exi t operator converts the output 
stream to simple tokens and returns them to the place from 
where requests originated. 

To use a monitor object we write 

z •*- use, (me, y) (2.14) 

The compilation of this statement is given in Figure 

2.6, The U operator sends the argument (y) to the domain 

-I 

indicated by me. The result is returned to U operator 
and assigned to variable z. 

Since the internal state of a monitor acts as a 
memory, the processing of a particular request may depend on 
the history of the previous inputs sent to the monitor. 

Id provides another nondeterministic operator: merge . 


It merges the streams specified in its argument list 
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nonde termini stic ally a nd creates a now stream. Expression 
(2.15) shows the use of merge ♦ 

C ■+• merge (A,B) (2.1 5) 

2 • 5 Programmer d efined data types 

In Id, a procedure definition value is treated 
exactly like any other value. This general view of a 
procedure allows Id to provide some very sophisticated higher- 
level concepts while requiring only minimally expended 
lower- level mechanisms. These higher-level concepts include 
programmer-defined data types (pdts) and operator extension- 
ality so operators such as n>ay he interpreted at 
execution time in the context of the types of their arguments. 

Expression (2.16) gives a pdt 'set* with four 
operations. Operation ’ s * decides set membership and 
returns a boolean value. '+ ’ denotes set insertion and 
returns a new set value. Hew set value is created using 
the procedure set-gen. 'U' and 1 n ’ denote set union and 
set intersection operations. 
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procedure set-gen (s,l) 

(y.*. procedure set (! function! f, ! arguments! u,v, 

! sot array! s, ! cardinality ! 1, set -gen) 
( if f= "e" then ( initial t -e- false ; 

for i from 1 to 1 while t do 
new t s [ i ] = v 
return t) 

elseif f = "+" then (if |ej (u,v) then u 

else set-gen( s+ [1+1 ] 

1+1 )) 

elseif f = "IT” then ( initial b +- v 

for i from 1 to 1 do 
new b -*-b+ s [i] 
return b) 

elseif f =" " then ( initial b set -gen ( ) 

for i from 1 to 1 do 

( i£| e | ( v ,s [ i 1 ) then new b ■*> b+s [i] ) 
return b) 

else error: (c'invalid set operation', f>)) 
return ( if s =? then compose (y, < , , , A ,0, set-gen > ) 

else comp ose (y, <,,, s, 1, set-gen>~))) 


( 2 . 16 ) 
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Actual values of sets are created by calling the 
procedure set-gen. The procedure set-gen returns a procedure 
value 'set' -with two frozen parameters s and 1 which 
characterize that set. Thus a pdt is always a procedure. 

To generate a new set a we write 

a «- set -gen (s,l) 

whore structure s contains the elements of a and 1 is the 
cardinality of a. Similarly to create an empty set we write 

a-*- set-gen ( ) 

An operation, such as set insertion (+), can he 
performed by writing 

b-t- 1 +| (a, 17) (2.17) 

Expression (2.17) creates a new set b and it is 
translated as 

b -*- apply (a, +, a, 17) (2.18) 

Expression 2,18 can also be written as 
b a + 17 

and in this case the meaning of operator + is determined 
at e xe cut ion time. 

If the operator + receives a procedure value on line 
a, it dynamically changes itself to an apply operator to 
evaluate the expression of the form (2.18). 
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2 . 6 An example 

In the previous sections we have discussed the mechanisms 
provided by Id. To show tho use of these mechanisms, we give 
an Id program to compute the Past Pourier Transform of a 
discrete signal sequence. Tho signal sequence is represented 
as a stream. 

procedure fast-fourier (X, j,n,w) 

!Xis the stream of the signal samples, 

n is the number of the samples in 

the original stream, w contains the 

the values of F , where l/k = 

__ .2n r } 

e ** n , and j=2 1 , where i denotes 
the level at which we are working. ! 
Init ially j should be 1 . ! 

(if empty ( rest (X)) then X 

l stream is divided into two parts containing odd and even 
numb er ed s am pie s . 

.else ( P,Q ( initial flag *■ true 
for each x in X do 

(if. flag then p «- x;q ■«- X ) 
else p +-\ q x) ; 
new flag 1 flag' 
return all p but x > all q but x ) ? 

S +■ fast-fourier (p, 2 * 3 , n, w) 5 
T fast-fourier (Q, 2 *j, n, w ) ; 

U,V 4- ( initial i *• 0 

for each s in S; t in T do 
a *■ w[n, i*3 ] +t 5 
u +■ s + a ; 
v s - a 9 
new i*-i + 1 
return all u, all v) 
return concatena te (U,Y))) 


( 2 . 19 ) 
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Keeping the asynchronous input and output behaviour 
of the streams in mind, a rough analysis of the above program 
will show that it takes 0 (n+log 2 n) time, whereas, a corres- 
ponding program on a sequential machine will take 0(n log 2 n) 
timo[ KA178b]. However, the above program requires atleast 
0(n) processors to execute in the time complexity of 
0(n+log2n). This proves the point that Id is ahlo to exchange 
processors with time. As a passing point wo would like to 
mention that most of the algorthims, such as morge-sort 
[KAT78a] etc., show this tendency. However, certain conventional 
algorithms which arc efficient on sequential machines turn out 
to be inefficient whon translated in Id. Thus it is 
reasonable to assume that to exploit asynchrony inherent in 
the problem it is not sufficient to translate existing 
algorithms into Id or any other dataflow language. Instead 
new algorithms must be invented and analyzed to derive 
benefits of asynchrony [Mai 78], 



CHAPTER 3 


SEQUENTIAL LOOPS, MIXED LOOPS, AND GENERATORS 

In "this chapter we discuss many aspects of looping 
constructs in Id and show that the idea of generators and 
iterators can he incorporated in Id -very easily. As a couple- 
ment to parallel loops wo propose sequential looping construct, 
that is loops of nested nature, and generalize these constructs 
to include any combination of sequential and parallel loops 
i.e. mixed looping constructs. Sections 3. 2 and 3*3 deal with 
sequential looping constructs and their efficiency considerations. 
Section 3*4 explains syntax and translation of nixed for each 
loop constructs. Section 3.5 shows how the idea of generators 
can easily be incorporated in Id. Section 3.6 presents an 
alternate translation of for loop in terns of for each loop 
using the concept of a special generator i to .j. This view of 
for loons makes the translation of nixed for loop constructs 
easy. Section 3.7 discusses a simplified translation of for 
each - while loop. Section 3.8 extends the ideas developed in 
Section 3.7 to control the generation of elements in a for - while 
loop and in a pdt. Finally Section 3*9 shows how the ideas of 
sections 3*4, 3.6, 3*7 and 3*8 can be used to translate mixed 
looping constructs with while clause. 
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3 « 1 Background and motivation 

As described in Chapter 2, Id [ A&P 78 ] provides many 
kinds of looping constructs to operate on simple as well as 
stream variables. Por the sake of comprehensiveness we list 
them below o 

(a) whil e p(x) do where p(x) is some boolean expression 

(b) for i from j " to k by 1 do and 

for i from j to k by 1 whil e p(x) do 

( c ) for each x in X do ’ " 

(d) for each x In X5 y in Y do 

(e) tor e ach x in X? y in Y while p(x,y) do 

Loop expressions like any other expressions in Id can be 
nested to any arbitrary depth. At present, loop expressions 
involving next in Id are different from (a) to (e). However, 
with a simpler implementation of next described in Chapter 4 
(section 4.5)? the present discussions will be valid to loop 
expressions involving next also. 

Our motivation to go for sequential and mixed looping 
constructsis to make programmer's task easier. Consider an Id 
program to sum all the elements of a n. xm matrix given in 
expression ( 3.1 ) . 
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( ini tj gala , sum. 0 
for i from 1 to n do 

new sum -e- sum + ( initial sum + 0 

for j from 1 to m do 
new sum sum + at i , d I 
return sun) 

return sum ) ( 3 • 1 ) 

Id forces one to initialize the sum twice. One can 
imagine the programmer's burden when the levels of nesting 
goes beyond three or four. Syntactically it will be more 
convenient for a programmer to write 

( initial sum ■** 0 
for i from 1 to_ n, 

3 1 to m do 

new sum *■ sum + a [ i * j } 

return sum) (3.2) 

However, translation of above construct is rather 
difficult in terms of existing compilation of for loops. The 
translation is considerably simplified if we view 1 to n as 
a generator generating successive values of the loop variable 
i. Another motivation to incorporate generators is to extend 
looping constructs to iterate over the elements of a pdt 
without giving undue emphasis on the order of enumeration. 
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Hiding the order of enumeration is a useful concept "because 
in many data structures, such as sets* there is no implicit 
ordering (in mathematical sense) defined over their elements. 
C1U [LSAS77 ] , ALPHARD [ SWL77 land EUCLID ILIILI1P77 Jalroady 
provide such an extended view of looping constructs to iterate 
over the elements of an abstract data type. 

3*2 A sequential looping construct for ID 

Since a somicolah is used to define a parallel looping 

construct (sue (d) and (c)) lot a cornua separating two 

clauses of a loop (as in expression (3.2)) define their 

* 

sequential or nested nature . Bunco the meaning of 
for each i in I , j in J do 

is that for each element of i talce each clement of J one "by 
one and execute one iteration of the loop. Hence the loop 
body will bo executed | i] X \ J | times as opposed to min{| I j T 
|j|}times (as in the case of a parallel loop). Implementation 
of a sequential loop is quite straightforward and is explained 
below in terms of an equivalent Id program not involving such 
a construct . 


flic use of comma hero is different from UCI dataflow 
llote 11 (revised). 
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( iiiitjn.1 x- *■ x Q 
for each i in I , j in J do 
new x <-f (x,i , j) 

return re) (3.3) 

The loop in expression (3.3) can be implemented as 

( initial x x Q 
for each i in I do 
new x *-( initia l ~x-«-x 

for each j in J do 
new x f ( x , i , j ) 

return x) 

r eturn x ) (3.4) 

There are some subtle issues involved in the correct 
translation of expressions contained in the return clause of 
expression (3.4). In equally efficient but somewhat more 
straightforward translation of (3.3) is given in (3.5). The 
expression in (3.5) does not affect the body of the loop. 

Only the input streams I and J are suitably enlarged to I 1 and 
J’, each of which has a length I I ! x I J I . ¥e prefer to 
translate expression (3.3) into expression (3.5) rather than 
expression (3.4) as the scheme of expression (3.5) is useful 
in translating mixed looping constructs. 
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(I ' , J 1 ( for each i in I do_ 

I'jJ 1 ( for each j in J do 

return all i , all j ) 
return all I ’ , all J * ) 
return ( initial- , - x x 0 

for e ach i in I'; .j in J * do 
new x f ( x , i , j ) 

return x) ) (3.5) 

The construct return all X returns a stream as opposed 
to a stream of streams. 

3.3 Efficiency of sequential loop e xpression 

Expression (3.2) for summing all the elements of a matrix 
can be translated into expression (3.6) in a mechanical way. 

( initial - sum 0 
for i from 1 to n do 

new sum «- ( initial sum sum 
for j from 1 to m do 

now sum sum + a E i , j ] 
return sum) 

return sum) (3.6) 

ffote that expression (3.6) is considerably less 
asynchronous than expression (3.1) due to the fact that all 
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the additions in (3.6) arc done sequentially. In expression 
(3.1) summation of elements within a row is still sequential 
hut it proceeds simultaneously for all the rows, While 
expression (3.1) will take 0(n) time, expression (3.6) will 
take O(n^) time. It is possible to mechanically transform 
expression (3.6) into expression (3*1) hut this is quite a 
difficult task because it involves meanings of many non-control 
operators in Id. It is reasonable to assume that in general 
when nested loop expressions are expressed as sequential loops 
a loss of asynchrony is involved. Thus the ease in writing 
may come at the expense of efficiency. 

3-4 Mixed looping constructs 

In order to generalize parallel and sequential looping 
constructs wo consider the following two proposals. 

(i) for each, (i in I; j in J), (k in I; 1 in L) do 

(ii) for each (i ini, j in J); (k in X, 1 in L) do 

The loop in (i) should go through min(|l| , 1 J| >X 

mint | Kj , | L|> iterations while the loop in (ii) should go 
through min{ | I| X \K\ X | L | }iter a tions . Semantics of 

expressions of type (i) are given in expression (3-7) while 
the meaning of (ii) is given in expression (3.8). 
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( I * » J ' , E ' , 1 ' *■ ( for each i in Ij j in J do 

I ' , J * , K* , 1 * 4 - (for each, lc in E; 


1 in L do 

return all i , a ll j , 
all k, all 1) 

return all I * , all J 1 , all E * , all L 1 ) 
r eturn ( for eac h- i in I ' j j in J f 5 k in E 1 ; 1 in L * do 


.)) ( 3 . 7 ) 

( I ' , J 1 ( for each, i in I do 

I 1 , J ’ <- ( for each .j in J do 

return all i, all j) 
return all I * , all J 1 ) 

K’ j, 1 * *• ( for each k in Z do 

E 1 , L * ( for each 1 in 1 do 

return all k, all 1) 
return all E ' , all L ' ) 

return ( for each i in I * , j in J 1 ; k in 1 in L ’ do 


.)) 


( 3 . 8 ) 


It is clear from these examples that we can build quite 
complex for each constructs by combining i in I type of clauses 
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either in a sequential wa; y or in a parallel way. Implement- 
ation of such complex for each constructs requires no 
additional base language operators. 

3.5 Stream producers as generators 

As pointed out in Section 3*1 a useful control 
abstraction present in GLU [LSAS77 1 and AXPEARD [ SWL77 3 is 
that of a generator. It offers a way of hiding the order of 
enumeration of the elements of ah abstract data type when 
such an order is unnecessary. For example a generator may 
enumerate all the elements of a set or all the elements of an 
array for addition without mailing the order of enumeration 
explicit. A related problem is to cnumera,te the elements of 
a programmer defined data type when its internal structure 
is not known* 

Something equivalent of generators can be defined very 
easily in Id using streams. In general any expression producing 
a stream can be treated as a generator. The elements of a 
stream X can be enumerated using a for each x in X do construct. 
Since the order of enumeration depends upon the construction of 
X, the problem of hiding the order of enumeration becomes the 
problem of hiding the generation of X. Since X will be gener- 
ated by an expression and the internal functioning of no 
expression in Id is visible from outside, the problem of hiding 
or abstracting is essentially solved. We elaborate this point 
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further by giving examples. Suppose we -want to sum the elements 
of a sot s where s is a programmer defined datatype in Id. he 
could accomplish this in the following way in Id . 

Define a function "enumerat c" on sets and include it in 
tho procedure set-gen (see Section 2.5). 'l'he procedure set 
(produced by procedure set-gen) when supplied with "enumerate" 
as a parameter would produce a stream containing all the elements 
of the set. l'he order of enumeration will depend upon the 
definition of the function "enumerate" inside the procedure set. 
The programmer using sets would just write 

for each e in j enumerate | (s) do 

Since the definition of a procedure application in Id 
allows streams to be input as well as output there is no problem 
in generating a stream from a pdt . It is also clear that such 
enumeration procedures can be defined for any pdt. However, wc 
can avoid generating a stream from the pdt, if wc desire so, by 
breaking the operation into two parts. Define a function on a 
pdt that gives all its elements stored in a linear structure 
with selectors 1 to n. A procedure that converts such an array 
into a stream is trivial to write. This method, however, fails 
with those pdts that have countably infinite number of 
elements. We will discuss this problem further in 


section 3.7 
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5 • 6 Ail alt ornate translation of for loops using a special 
generator 

Values of i generated by the for loop 
for i from j to k do 

can also be modelled as the following stream 

1 * ( initial i j 
while i < k do 
new i -f- i+1 

return all, i) (3*9) 

The stream I can now be used in place of from j to k as 
for each i in I do 

Event hough the loop fo r i from j to k do results in a different 
base language translation, the answers produced by two loop 
expressions will be identical except in one detail. Suppose 
the last value of i is to be returned from the loop. The 
from j to k loop will produce the value k+1 while for each 
i in I loop will give an error. Several solutions to this 
minor problem are possible and we will not discuss them here 
any further. We would like to point out that both for loop • 
and for each loop in this case are equally efficient. 

One might be wondering about our motivation to 
translate for i from 1 to n type of loops into slightly more 
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complicated for each, i in I type of loop* As we hope- to show 
in tho next few sections this approach helps considerably in 
translating sequential looping constructs of the type given in 
expression (3.2). Without this technique of converting for 
loops into a for eac h loop implementation of the following 
construct is extremely difficult. 

for (i from 1 to n, j f rom 1 tom); 

( k from 1 to q, 1 from 1 to r ) do (3.10) 

Let us introduce a now stream expression of the following 
type in Id 

I o to k. 

The meaning of this expression is given in (3.9). The trans- 
lation of the mixed looping construct of (3*10) now can be 
explained as follows: 

(I-*- 1 ton; j «- 1 to m; K 1 to, q ; L 1 tor 
return ( for each (i in I, j in J); (k in S, 1 in L)do 

...)) (3.11) 

Similarly we can translate any type of mixed looping 
construct . 

3.7 for each - while type of loop revisited 

Consider the following type of loop expression whoso 
translation is discussed in IAG-P78 ] in some detail. 
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( initial . x «- x Q 
for each h in B while p (b,x) do 
new x ^-f(byx) 

return x) (3.12) 

The main feature of the translation is that a signal 
stream S controls the release of tohens from stream B into the 
loop. Or equivalently a token of stream 3 enters the loop 
on demand only. How we will describe a slight modification 
of the scheme given in [AGP 78 3. 

The translation of expression (5.12) can be simplified 
to the one given in Figure 3.1 provided the loop of expression 
(3.12) satisfies the following property P. 

p(bi»Xi) = false b i+ .j = est 

where b^ is the ith token of stream B and x^ is the input value 
for the ith iteration of the loop. Tho property p guarantees 
that stream B runs out of tokens exactly when the loop predicate 
p turns false. 

In general property P does not hold for a loop. However 
we can always convert any for eac h - while loop to one for 
which property p does hold good. The technique is explained 
below by using the same example (i.e. expression (3.12)). 
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However, now we assume that property p is not satisfied by 
the loop in (3.12). 

(x, S 1 ■*- ( initial x Q 

for each b in B 1 while p ( b ja) A b £ e do 
now x *■ f (b,x) 
return x, all true ) ; 

S +• cons ( true , S'); 

B T 4 . cxif (B, S, e) 

return x) (3*1 3) 

It is clear that stream B r alongwith predicate p(b,x) 
b ji s satisfies property p provided »noe tokens arc presents 
in B. This is the same condition as in tA&P78b] . The trans- 
lation of expression (3.13) differs from the translation of 
expression (3.12) according to the rules given in [ A&P78 3 
only to the extent that e xif and cons will be outside the loop 

domain. 1 

3.8 Controlled generation in a for - while, loop and in a pdt 

Wo consider the translation of the following looping 
construct 

for i from 1 to n while p(x) do (3*14) 

An equivalent form involving generators will be 

for each i in I while p(x) do (3-15) 


where I is the stream 1 to n. 
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'The loop in (3.14) generates a value of i only when 
p(x) for the previous value of i is true . Hence if n >10 
and p(x) turns false at the 10th iteration, the values 11,12, 
n for i are never generated. On the other hand, loop 
in (3.15) will always get in stream I the whole sequence 
1 , 2 ,..., n eventhough it will simply absorb value 11 , 12 ,.... 

If n happens to be a infinitely large number, the program 
in (3.15) will not terminate while in case of (3.14) it will. 
This descripancy can be resolved by producing the tokens of 
stream I on demand. The technique described in Section 3*7 
for generating a signal stream can be used to control the 
production of tokens in stream I. The details are given 
in expression (3.16). 

( . . . , S’ *■ ( initial • 


for each i in I while p(i,x) A i ^ e do 


return . . . , all true ) 

S -e- cons (true, S')? 

I ( initial i ** 1 

for each s in S do 

if i <L n then new i *■ i+1 ; i ' i 
else new i *• e; i ' ■*- e 
return all i 1 ) 


return 


) 


(3.16) 
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The signal stream S must be used in generating stream 
I as opposed to just controlling its size after the whole stream 
I has been generated. For example if we write 

I ' ( init ial i*- 1 

while, i <n do 
now i -e-i+1 
retur n all i) 

I oxif (IS S, e) (5.17) 

then the whole purpose of stream 3 is defeated. 

Finally \jq discuss how this idea of controlled generation 
may bo used in conduction with a pdt . A pdt is essentially a 
procedure and hence can accept a stream as an input parameter 
and produce a stream as an output parameter. A programmer can 
generate an appropriate signal stream S and use it in enumer- 
ating the elements of a pdt. The technique for generating 
and using signal stream is same as the one described in the 
above examples. We think that all such programming should be 
explicit jr so that no new semantic extensions arc required. 

We explain by giving a very .simple example where the 
elements of a set are to be enumerated until an element 
satisfies some predicate p. Lot s bo a pdt representing 
a set. 
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(! the calling procedure ! 


• . , S '-(-(initial 


for each z in X while "1 p(x,Y) Ax / £ do 


return . . . , all true ) i 
S •+• cons (true, S' )j 
X (enumerate | (s,S)j 


( 3 . 18 ) 


Internal structure of s would look something like the 
following 
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procedure sot (f,u,v, set-gen, a,l,S) 

! all formal parameters have the usual moaning 
S - a stream parameter has been added! 

(if f = ... 

* 

* 

* 

elseif f = "enumerate' 1 then RESULT -t- ( initia l i 1 

for each signal 
in S do 
if i <_1 then 

x +■ a t i ] 
else x e 
return all x) 

(3.19) 


3.9 Mizod looping construct with a while clause 

The loop of the type for each i in I, j in J - while 
p(i,3,x) do can be compiled in two steps. First transform the 
sequential loop into a parallel loop according to the method 
discussed in section 3.2 . Hence we will get 

for each i in I 1 ; j in J 1 while p(i,j,x) do 
which can be translated either according to the rules given in 


[A&P78 ] or the rules given in section 3.7. Hence all looping 
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constructs involving streams can tc translated. 

The ideas developed so far can bo suitably extended to 
specify efficient translation of sequential and mixed loops of 
the following typo; 

for i from 1 to n ? 3 from 1 to m while p(i,3,x) do_ (3.20) 
for (i from 1 to n, 3 from 1 to n); 

(k from 1 to q, 1 fro m 1 to r) whil e p(i,3,x) do (3.21) 

in extension of the idea present in the translation of 
expression (3.1 4) to expression (3.16) leads to the following 
translation of expression (5.20) 

(...,» S*- 4 - (initial . 


for each i in I; j in J while p ( i , 3 , x ) A 

i^e A 3j£ e do 


return . . . , all true) 

S cons (true, S 1 ) 

I , J •*- ( init ial i **■ 1 ; 3 1 

for each s in S do 

( if ( i <. n) A ( 3 < m) then new 3 j +1 ; i * i j 3' * 3 
elseif (i< n)i (o=n) then now ~i-f-i+l mew 3 1 J 

i* ■*■±9 j' 3 

else i’+e? 3 / -«-e ) 
return all i * , all 3 * ) ) 


( 3 . 22 ) 
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It should bo noted that in expression (3*22), the first loop 
satisfies property P and the moment i f and get the value 
both the loops terminate* 

A translation of mixed looping construct of (3*21) is 
given in expression ( 3 . 23 ) in terms of the rules used in 
expressions ( 3 * 8 ) and ( 3 * 22 ). 

. ( * * • 9 ini c ial * 

« 

for each i in I; 3 in J; k in K; 1 in L 

while p(i, j ,k,l,x) A ijA e A3^ eAk^ e A IjL e do 


return . . * , all true ) 5 
S cons ( true , S’); 

I , J ( initial i + 1; q 1 

for each s in S do 

(if (ii n) A ( u) then new 3 3+1 5 i ' i; 3 ’ 3 

elseif (i< n)A(3=m) t hen new i -t-i+1 ; new j 1 ? 

i 1 -f-i j ' <• 3 

else i ’ e ; 3 1 ^ £ ) 
return all , i 1 , all 3 ' ) 

K,L ■*" ( initial k«- 1 1 

for each s in S do 

(if (k<. q) A(l< r) then new 1 •*- 1+1 l k ’ k j 1 ' 1 

elsei f (k< q)A(l=r) then new k h+1 new 1+- 1 j 

k 1 ■ f "k; 1* + 1 

else k *+■ e; l‘«- e ) 
return all k 1 , all 1 ’ ) ) 


(3.23) 



50 


5.10 Summary 

In this chapter we have modified the implementation of 
for loops from that given in [ A&P78 ] and as explained in 
Chapter 2. This has been done to extend looping construct to 
include sequential and mixed type of loops. An explanation 
in Id is offered for the implementation of for each - while 
loop. This new explanation with its virtue of being in Id is 
applicable to many programming situations where a controlled 
generation of elements is required. At this stage it seems 
that the only fundamental looping scheme is 

for each i in Z; y in Y while p(x,y) do 

Both the while loops and for each- loops without whil e clauses 
can be explained as special cases of the above loop. All the 
other sequential and mixed looping constructs have already been 
defined in terms of this fundamental parallel looping construct 
with a while clause. 

Generators as used in the literature so far can be 
expressed in Id without any extensions, bince pdts arc 
basically procedures, controlled generation of elements even 
in case of a pdt is no problem. 



CHAPTER 4 


STREAH STRUCTURES 


In this chapter we discuss the concept of arrays of 
streams, which will ho called stream structures , and show their 
usefulness in modelling the problems related to the area of 
resource management. After motivating to stream structures 
in Section 4.1 , we review the dynamic stream construct of Id 
in Section 4.2 and show its use by an example in Section 4.3 • 

In Section 4.4 it is shown that stream structures can be 
incorporated in Id without extending the base language. We 
extend the semantics of some base language operators in 
Section 4.5 to permit streams as creation time parameters for 
Id monitors. Finally in Section 4.6 a complete example showing 
the use of stream structures is discussed. 

4- • Motivation s 

A problem in the area of resource management is how to 
maintain a queue of requests for a resource or a group of 
resources. In many instances a distinction among requests has 
to be made depending on their certain attributes, such as 
priority etc., to implement various scheduling policies 
tBri 73, Sha 741. In such cases many queues have to be 
maintained to distinguish between different requests. 


U. f. KAfvFUR 
CENT 8 At LP RaRY 

54921 
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Streams in Id offers a natural way to model the 

• 7 ^ 

first-in- first -out queue . In order to maintain several 
queues a stream variable can bo defined for each queue. In 
a monitor definition in Id an entry port corresponding to 
each queue can also be defined. However, if the number of 
queues is largo and dynamic addition and deletion of queues 
is required, then certainly, we cannot use the above idea. 

What wo need is a model in which we can address a queue in 
the form A Ci ] , where A is the group of queues and i is 
the distinguishing attribute of the queue we are referring to. 

The dynamic stream construct in Id [AGP771 offers a 
way of maintaining a variable number of queues, however, it 
imposes a restriction that all streams comprising a dynamic 
stream have to be dealt in an uniform manner. Our main 
motivation to go for stream structures is to provide a 
mechanism to model a large and a variable number of queues in 
which individual queue can be addressed and operations can be 
performed on its elements. 

© 

4.2 Dynamic streams 

As described above a dynamic stream is a set of streams 
whoso elements are to be treated in an uniform manner. Ho 

*In this chapter streams and queues will be used synonymously, 

& This description of dynamic streams is taken from personal 
notes of Dr. Arvind and Wil Plouffe. 
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explicit mechanism for selecting a particular stream is 
provided. Id provides exactly one construct for the creation 
and manipulation of dynamic streams. The construct is 
explained in expression (4.1). 

( d switc h I *■ S via L 
do 

J ( ... ) 

« 

dmerg e J via M) (4.1) 

The operator d switch creates a distinct logical stream 

I . for each distinct value j in the stream L. Stream I . will 
J J 

contain only those tokens of S for which the corresponding 
token of I has the value j. As an example 

d suit ch X "** {ayhyCydyOylyg j vi a [ 1?5?I?3?3?1?13 

would create the dynamic stream I with logical streams 

I-j x. [n>f ?§] f Tg ~ ~ f OjdyG j 

The operator drnerge is the inverse of d switch and 
creates a single stream using the dynamic stream J according 
to the specification stream M by removing one token from the 
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logical stroani J. when the next token fron M carries the 

J 

value j. As an' example , if the value of the stream M is 

12.3.3.1 >3,1,1 ] f and the stream components of dynamic 
stream J are 

4-] = [ a , h , c ] , — [d] 5 = f c,f ,g ] 

then dmerge will produce stream [ d,e,f, a,g,h,c] . 

The operators d switch and dmerge are deterministic in 
nature. The code enclosed between d swit ch-dme rg e pair is 
logically created and independently acted upon by each stream 
of a dynamic stream. Inside a d swit ch - dmerg e pair a 

programmer treats dynamic stream like an ordinary stream except 
that he cannot use ordinary streams in conjunction with 
dynamic streams. • Below wo discuss the U-interpreter semantics 
of the operators d switch and dmerge . 

4 . 2 . 1 c 1 swit ch t 

As mentioned above d switch creates a distinct logical 

stream (I •) for each distinct value (j) in the selection 
3 

stream (L) . It does so by changing the context part of the 
activity name , We give the u-interpreter semantics of 
d swit ch used in the dynamic stream construct of Figure 4*1 . 



logical streams / 3 

/ • • 


1'lgure 4.1 



* 


A dynam i o st r c am co not ru ct 
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u.p.s.i - - input; porfcl (selection stream)= {<0, ,k>{1<k<n } 

port2 (data stream) ={<^.,k>|1 ^£<n x } 

output; (dynamic stream)= 

U ( C 1 _^ est. »(kg n « X, . count ( C, .k) >. 
1<k<n K x .J£ k 

< (u» C-^) .p.t .i >>} 5 jr )j 

TJ {<<est, count (j, n )> , 
j eDL • c 

< (u.j).p.t.i »} ) 

■where D 1 =s {jjj = C-, for some k<n > 

count (j,k) =| {iJC^j and i < k > ( 

Thus to create logical streams context part of the activity 
name is changed from u to u.C^.* Since a logical stream is created 
for each distinct value of C-^, the logical streams are uniquely 
defined hy the context part of the activity name. A logical 
stream is treated as an ordinary stream, and, thus it cannot 
have ’’holes" in it. Por this reason d switch maintains the 
number of elements passed to each logical stream hy the function 
count . As soon as an est on selection stream is encountered, 
est tokens are produced for each logical stream. DL maintains 
all the distinct values for this purpose. 

4*2.2 dm erg e ; 

As mentioned before 
dmerge J via M 

creates a single stream using the dynamic stream J according 
to specification stream M. This is done by taking an element 
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fron tlio logical stream I. when the next olcncnt from tho 

J 

stream M carries the value 3. 

We give the U -interpreter senantics of dm erg e used 
in the dynamic stream construct of figure 4.1 . The description 
of d merge is complicated hy tho fact that all streams of the 
dynamic stream have separate activity names and hence 
cannot be sent to the same operator „ Thus dm erg e has to be 
broken into two primitive operators; a nerge„ and a merge_ . 

1 “C "“‘St 

The schematic representation of operators merge c and rnerge ^ 
is given in figure 4.2. 

a. merge ; This operator operates on the control stream and 

Q 

for each token received by it, a token has to be produced by 

the dynamic stream construct of figure 4.1. merge,, essentially 

produces a stream of tokens for each of the merge operators. 

8 , 

The kth token received by the merge operator carrying value c 
is forwarded to the merge operator operating on the logical 

> ( 3j 

stream I to produce the kth token in the output stream. 

u.p.s.i - - input ; (control stream)={< C-^jk >| 1 <.k <_n, > 
output =i V ; (k^n->{< k, count (C^ ,k) > , 

<(u.C l£ ) .p.merge a .i >} ; 
{< est , k*<u.p,t.i>} ) 
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Figure 4.2 Schematic representation of merge a and 

merge.* 

o 
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Since merg e operator is identified by the context 
(u.C-jP of the logical stream on -which it is operating, the 
context part of the activity name of the control tokens sent 
to merge operators is also changed to u.C k . The merge Q 
operator has strong similarities with the d switch operator, 
however, merge produces only one final est token as opposed 

0 twatr -r- -t 

to an est for each merge . 

_St 

h « merge ; A merge^ operator is needed for each logical 

stream I. of the dynamic stream I. A token produced hy the 
3 

dmerge comes from one of the merge operators. The merge 

a S t 

operator which produces the kth token of the output stream is 
picked on the basis of the kth token received by the merge c 
operator. 

(u.j).p. merge «i - - input; port 1 (control stream) 

cl 

= {<C k ,k>| 1 < k< p c > 
port 2 (data stream) 

={<2^.,k >'|1< k ip^.} 

output; ( stream) = U (lc <p*-{<X , Cv> , 

1<h<p d k 

< u.p.t.i >y, 
k=p 0; C) 

JL 

It should be noted that the dynaaic stream construct 
of Figure 4.1 produces valid base language program. However, 
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the base language schema of figure 4.2 will be self cleaning 
only under certain conditions and those conditions , in general? 

cannot be checked without executing the program. For self 
cleaning streams C-j , C 2 > must have the same number of each 
integer present in them. 

4.3 A disk scheduler monitor 

We illustrate the use of dynamic streams by writing a 
disk scheduler. To minimize disk-he ad- seek-time we implement 
a scan policy in which disk head moves in one direction and 
processes all the requests that fall ahead of it. If no 
request lie ahead then the direction of scan is changed and 
the same rule is followed again. If the disk head is busy and 
a new request for cylinder c arrives, the counter count 
associated with the cylinder c is incremented. Similar to 
Ho are 1 s monitor[ Hoa74 1 we maintain a queue of requests for 
every cylinder with the help of a dynamic stream DR2Q. The 
scheduler produces a stream giving the cylinder number of the 
next request to be processed. This stream is then used to 
form a dynamic stream of triggers; DTRIG, which in turn is used 
to send signals to queues DREQ. 

Once a request is allowed to proceed, it calls on another 
monitor 'disk control' to actually seek the desired cylinder 
and transfer data. This monitor may contain some of the actual 
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hardware of disk controller. A reply from disk control 
monitor signifies that the request has teen processed. The 
disk scheduler monitor produces a result stream RESULT which 
is used to signal the scheduler that the current request 
has "been processed. A schematic of disk scheduler is given 
in Figure 4.3 and Id implementation is given in Figure 4.4. 

¥ c will not discuss the 'disk control' monitoi*. 

4.4 Stream structures 

As pointed out earlier, dynamic stream construct 
provides no way of selecting a particular logical stream. 
Consider a slight modification of the problem of disk 
scheduling discussed in Section 4.3. Suppose the disk scheduler 
should access two different physical disks depending on which 
group does the cylinder number belongs to. Solution of the 
problem using the dynamic stream would require the use of a 
case statement operating on all logical streams thus no longer 
maintaining problem structure in the solution. This solution 
is also likely to be inefficient in some cases. Wo will 
discuss these points further in Section 4.6. 

In fact the dynamic stream construct in Id solves 
two problems associated with the resource management. ; 

1 . The d switch operator is used to form large and var- 
iable number of queues. In doing so initial 
ordering of requests is maintained only within a 
particular queue. 
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REQUEST 



Figure 4*3 Schematic of disk scheduler monitor 
of Figure- -( 4 *-4 ) « 



monitor disk scheduler (dc) 

! dc is the disk control monitor for the disk this scheduler 
is supposed to schedule! 

( entry BEQUEST do 

REQCYL +■ (for each req. in REQUEST do 
return all req.c) ; 

! req.c gives the cylinder numher! 

RESULT ( dswitch DRBQ «- REQUEST via REQCYL j 


DTRICt «- CYLINDER via CYLINDER 
do 

DRESULT •*-( for each dreq in DREQ; 

t in D'TRIG do 
dres -f- use (dc, dreg ) when t 
return all dres) 
dmorge DRESULT via REQCYL) ; 

X merge (REQUEST, RESULT) 5 
! This is scheduler code! 

CYLINDER *■ ( initial busy 4 - false ; direction 4 - "up” ; 

head + 0 

for each s in X do 

if z.type = "request" 
then ( if busy 

then new count Ik.cR- count fe.ch-1; 
cylinder X 

else new direction ■+• (if x.c > head 

- - then "up" 

else "down" ) | 


new head +■ c ; 
new busy +■ true ; 
cylinder + 0 ) 

else ! it is a done signal! 
new count, now head, new, direction, cylinder 
•‘-findnert (count ,head , cylinder ) ; 
new busy + (if cylinders x then false. 

else true ) ) 

return, all cylinder but A) 


exit, RESULT) 

Tfimrfi 4.4 Code for disk scheduler monitor 
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2. The dm ergo operator is used to restore the initial 
ordering by choosing the appropriate control stream 
(see the use of stream REQCYIi in figure 4.4). 

Another solution to maintain a variable number of 
queues in which individual queue can bo addressed is to introduce 
array of streams ~ which will be called as Stream Structure . 

A stream structure is a stream in which each element 
has an associated qualifier which will be called ’’selector' 1 . 

The selector can be part of the activity name or part of the 
data itself. For further discussion wo will assume it to be 
the part of data. Thus no new Id constructs or base language 
operators are required to deal with stream structures. An 
element of the stream structure is of the forms 

<<:< "data": x, "selector”: int > , k> , < activity namo>> 

where int is a selector value. We will assume all selector 
values to be integers. A stream structure can also be 
regarded as an ordinary stream of structure values. Hence, all 
operators and constructs defined on simple streams arc valid 
on stream structures also. In addition we define two Id 
procedures which are useful when dealing with stream structures. 

a. select (A,i): A is a stream structure and i is a selector 
value. The result of procedure invocation is a stream 
containing those elements of A whose associated selector 
value equals i. Expression (4.2) gives details of the 
procedure. 
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pr oc edur e select (A,i) 

( for eac h a in A do 

res -s- (if a t ’’selector” ] = i then a f "data" 3 

else. X) 

return all res but. X) (4*2) 

b. append (A,B,i): A is a stream structure, B is a simple 

stream, ahd i is a selector value. Result of procedure 
invocation is a stream structure containing those elements of 
A whose selector value is not equal to i and all elements 
of B with their selector value m a de' equal to i. Expression 
(4.3) give s details of the procedure. 


procedure append (A,B,i) 

(RES1 (for each a in A do 

resl +• (if a t "selector” ]= i the n X 

else a) 

return all resl but X ) J 
RES2 + ( for each b in B do 

res2 *■ < "data" : b, "selector”;! > 
return all res2) 

retur n merge (RES1 , RBS2) ) (4.3) ( 

merge in the return clause of the procedure append is 
used to cater for infinite streams. It can he replaced by 
concatenate operator, if only finite streams are being considered 



Tlie use of merge makes the procedure append nondeterministic 
in behaviour. However, if we allow only for each, loop and 
the procedure select to operate on stream structures, then 
either all the elements can bo dealt in an uniform, manner or 
a particular stream can be selected. Since merge does not 
change ordering of elements in component streams, the selected 
stream is always deterministic. Thus under these limitations 
the ultimate result will always be deterministic. 

4.5 Extension of Id monitors to include streams as creation 
time parameters 

The problem of maintaining queues is solved using stream 
structures. However once selection of a particular stream of 
a stream structure is done, the position of the elements of 
the selected stream within the original stream is lost. 

However, for correct functioning of Id monitors, it is required 
that a strict correspondence between the elements of input 
and output streams be maintained . Hence, for stream structures 
to be useful in resource management problems, we need a way 
to restore the original order. We extend the monitors to 
include streams as creation time parameters and then we will 

*Hote if this is not the case, that is, the answer corresponding 
to the ith token of the input stream is in the jth position 
(j^i) of the output stream then the sender of the ith token 
will get the wrong answer (i.o., the ith token from the 
output stream) • 
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uso the extended monitor and dynamic streams to alter the 
ordering of elements in a stream structure* 

We -will allow the streams to be parameters in the 
construct create (see Section 5.2 of [ AG-P78 ] ), For each 
stream parameter in create wo pro-wide separate port in operators 
O 2 and MBEG-IN. A schematic of such extension is shown in 
Figure 4.5. Below we give the activity name manipulation by the 
operators , Cg and MBEG-IN. 

i. C.j : This opora/fcor needs no change to accomodate streams 
as creation time parameters. 

u . c • s.j .i - - input = c Q 

output ; portl = < (u f *c .mbogin.l ) , 

** III 

< u.c.S2«i»‘l >> 
port 2= (u 1 .c Q . entry .1 ) 

ii. C 2 s A separate port is created for each stream parameter* 

u*c.s 2 .i - - input; portl = (u 1 .c^.mbegin.1 ) 

port 2= x 

port3( stream) = {< y»k >| 1 <~k < r^.} 
output : portl = <x, <u* . c^.mbegin.1 ,1 >> 
port2(stream )={< <y,k> 

<u’.c .nbegin.1,2 » 

HI 

| 1 < k £ n y } 
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Thus the operator C 2 will renain in exist once until 
it either receives est tokens on all streams or the monitor 
object is destroyed. 

iii. HBEC-IN ; 

u ' .c .nibcgin.1 -* - input: portl (simple )=x 

port2( stream) = {< y,lc>jl <k — n) 

y 

output: portl (simple )=x 

port 2 ( stream )= {<y,k>| 1 <k< n ) 

A raonitor to alter the ordering of elements of a stream 
structure is given in expression (4.4). 


monitor n c rfc s ( S TRE AH- S T ) 

( entry SELECTOR do 

RESULT *-( d switch DSEL -«* SSLECTOB via SELECTOR? 

D STREAM- ST ♦ STREAM-ST via 
(for each s in 

STREAI-'I-ST do 

return all s ["selector" ]) 


do 

RES-** ( for each ds in DSTREAM-ST? 

dsel in DSEL do 
return ds when dsel) 
drnerge RES via SELECTOR) 


exit RESULT ) 


( 4 . 4 ) 
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Use of an instantiation of such a monitor by 
use (dnexts,c), where dnexts is a, monitor object created from 
monitor definition next s. Trill give the next element in 
the logical stream DSTREAM-ST « This is in fact, the next 

G 

element whose selector value is c in the stream supplied to 
dnexts at creation time. 


The effect of monitor nexts can also be achieved by 
providing an entry port for stream STREAM- ST without extending 
the monitors to include streams as creation time parameters. 
Such a version of monitor nexts is given in expression (4.5) 


monitor nexts ( ) 

( entry selector; SELECTOR? data; STREAM- ST do 

RESULT 1 ■** ( d switch DSEL«- SELECTOR via SELECTOR? 

D8TREAK-ST -^STREAM- ST via 
( for each s in 

STRE AL1-ST do 
return all st 'b elect or "] 


do 

RES- f - ( for each ds in DSTREAM-ST 

dsel in DSBL do 
r eturn all ds when dsel) 
dmerge RES via SELECTOR) ; 

! we also need to acknowledge the processes sending 
elements of STRBAH-ST at entry port "data"! 

RESULT 2 ( for each s in STREAM-ST do 
return all ’acknowledged*) 

exit selector; RESUTT1 ? data; RESULT 2) (4.5) 
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The stream STREAK-ST is sent to an instance of nerts 
element "by element as explained in program segment of 
expression (4.6). 

dnexts create (nexts, ) 

(initial flag-*- anything 
for each s in STREAM" ST do 

ack -t- use (dnexts.data,s) when flag? 
now flag -<-ack 

return ... ) (4.6) 

Rue to unfolding of loops in Id second iteration of loop 
in expression (4.6) may produce s before first iteration does 
so. Since the entry operator is nondeterministic, it will 
alter the ordering of elements in STREAM— ST • To avoid this we 
used a flag in expression (4.6). Flag will get a new value 
for the next iteration only when the previous iteration has 
completed the use of the monitor, thus forcing serial use or 
monitor instance dnexts. We want to emphasize the fact that 
any time a monitor is to be used sequentially it should be 
explicitly programmed by the programmer. Actually we are 
tempted to introduce a new U operator in the base language 
that will automatically ensure sequentiality in the use of a 
monitor. This new operator will receive ah acknowledge 
signal from the entry of the monitor as soon as a token is 
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received. The advantage is, of course, one does not have to 
program explicit acknowledge signals, generating which can he 
quite clumsy in some cases. 

Though monitor nexts in expression (4.5) is equivalent 
to monitor nexts in expression (4.4) as far as overall 
behaviour is concerned, monitor in expression (4.4) reflects "kh- e 
nature of the problem more clearly than the monitor in 
expression (4.5). Also limiting creation time parameters of a 
monitor to be simple variables is reall3 T not necessary. 

Inside monitor nexts we use the dynamic streams to 
maintain queues and alter ordering. Such a use of dynamic 
streams off exs two advantages; 

i. Dynamic streams can be made accessible only to 
monitor nexts thus avoiding the problem of 
unintentional mixing of dynamic streams with simple 
streams by users. This also gives a kind of 
desirable modularity to the program. 

ii. Semantics of monitor nexts is easier to understand 
than the semantics of a general dynamic stream 
construct . This is duo to the fact that net effect 
of monitor nexts is only to alter the ordering 
unlike dynamic streams which perform two functions 
at a time. 

As a passing point wo would like to mention that the 
concept of monitor nexts can be applied to model next construct 
on streams. Expression (4.7) gives a monitor whose behaviour 
is equivalent to construct next. 
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monit or next (X) 

( entry REQ do 

1 ^- oxif (X,REQ, e ) 5 

RES ■«- ( for each, reel in R3Q; y in Y do 
return all y) 

e xit RES ) (4*7) 

As an example consider an Id program which uses the next 
operator. 

Z *■ ( for each b in 3 do 

z ( i£ h then next X 
e ls e next Y) 

return all z) (4.8) 

The above program can be written using monitor next ass 

xn ext ■+• create (next ,X ) ; 
ynext creat e (next ,Y ) 

Z ( initial xsig-s- anything ; ysig ^. anything 
for each b in B do 

if b then z •♦- use, (xnext , xsig) ; 

now xsig z;new ysig anything 
else z use (jnaext, ysig) ; 

now xsig anythin g.; new ysig z 

return all z) (4.9) 
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4.6 An example 

Consider a multi programmed , multiprocessor environment. 
Suppose each processor is capable of performing several 
different tasks, and the set of tasks performed by any processor 
is exclusive of the sots of tasks performed by all the other 
processors. There are several requests for each typo of task. 

We want to write an interface monitor which will schedule the 
tasks on the processors. Wc will assume that there are onky 
two processors and different task typos are numbered from 
1 to 2n with 1 to n running on processor 1 and n to 2n 
running on processor 2, Real world examples of such a system 
would bo a system like CHAT 1 tRus78l having separate processors 
for scalar and vector operations or a system in which one 
processor is dedicated to string operations (compilation etc.) 
and one processor to arithmetic calculations (floating point 
arithmetic unit). Each task type has a priority associated 
with it, and the number of requests waiting in its queue. These 
numbers are maintained in two arrays: priority and count. A 
procedure "change- priority 11 changes the priority of tasks 
dynamically depending on the number of requests waiting. 

Another procedure "highest -priority" gives the highest 
priority task number, whose queue is not empty. The number 
of the highest priority task is between 1 to n or n to 2n 



75 


depending on whether the flag is sox to 1 or 2. If no such 
task is found then the procedure "highc st-prior ity" returns X. 
Each processor has an associated monitor processor [ I] ; 
i=1 j 2 which may ho the actual hardware of the processor. This 
monitor returns its number i in result, "processor" to 
interface monitor when it completes the scheduled task. A 
complete description is given in expression ( 4 . 10 ). Me 
maintain separate queues for each typo of task using stream 
structure ST-REQ. 

mo nit or interface (processor, count, priority) 

( entr y REQUEST do 

! streams REQUEST and TRIG- are changed to 
stream structures! 

ST-UJ3Q ( for each req in REQUEST clo 
streq <"data" sreq, 

"selector": req. task> 
return all streq ) i 

ST-TRIG (! TRIG is returned by scheduler code ! 
for each trig in TRIG do 
sttrig <"dat a" : trig, 

"selector": trig > 
return all sttrig ) 5 
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ilESI ( for i fr om 1 to n do 

ST-REQl "*■ select ( ST-REQ , i) j 
ST- TRIG 1 4- soloct (ST- TRIG, i) ; 

RRES1 ■*- (for each strcql in ST-RSQ1 

sttrigl in ST-TRIG-1 do 
result 4- use (procossor[ -1] , 
streql ) 
when sttrigl 5 

rrcsult 4- <”data 1 ': result, 
"selector";! > 
return all rresult) 
return all RRBSl ) j 
RES2 ( for i from n to 2n do 

ST-RBQ 2 4- soloct (ST-REQ, i) ; 

ST-TRIG2+- select (ST- TRIG, i) ; 

RRBS2 4- ( for each streq_2 in ST-R1Q2 

sttrig2 in ST- TRIG 2 do 
result use (processor [2], 
streq2) 
when sttrig2; 

rrosult ■*■< "data” : result, 
"selector"; i> 
return all rresult) 
return all RRES2) ; 

RESULT +• merge (RESl , RES2) 5 
X “■ merge (REQUEST, RESULT) 5 
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! following is scheduler codo ! 

TRIG- ( initial . . . 

for each x in X do 
if x.'typo = s, roc|” 
then (if x.task^. n 

thcn ( if status [processor [ 1 ] 3="free'' 
then trig -«-_x*task 
olso now count [x.task ] 

count [x.task ] +1 5 
change-priority (priority, 

c ount ) i 

trig X ) 

olso ( if status [processor [ 2 ]]= i, frGG' 
then trig x.task 
else no T .r count [ x .task ] + 

count [ x.task ] +1 ; 
chang o-priority (priority, 

count) | 

trig X ) ) 

olso ! it is a done signal from processor 
monitor! 

(if x. "procossor"=1 
then trig + highe st - prior it y( 

priority, count, 1 ) ; 
status [ processor [ 1 ] ] 

( if trig= X then "free 11 
else "‘busy") 
olso trig highest -priority ( 

priority , count , 2 ) ; 
status processor [ 2 ] ] 

(if trig= X then "free" 

olso "busy" ) ) : 

return all trig but X) ; 
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S following is code for restoring ordering! 
rnerts create (nexts, RESULT) ? 

EX-RES ( initial flag anything 

for each req in REQUEST do 

exres *■ vise (rnexts, req) when flags 
new flag erres 
return all exres) 

orit EX-RES) (4.10) 

Procedures "change-prior itv" and "highest -priority" 
are easy to write and wo will not discuss them hero. 

The monitor interface, if written using dynamic streams 
will look something likes 

monit or interface (processor, count, priority) 

( entry REQUEST do 

REQ *■ (for each req in REQUEST do 
return all req. task) ? 

RESULT ( d switch DREQ +■ REQUEST via REQ? 

DTRIG- TRIG via TRIG 
do 

RES ■*- ( for each dreq in DREQ? 

dtrig in DTRIG do 
res -e- (if dreq, task< n 

then use ( processor [1 3, 
dreq) . . . 
elseif dreq .t ask > n 
dreq. t ask 2n 
then use 
(processor [ 2 3, 
dreq) ... 
else 'error 1 ) 




) 


exit RESULT) 


d merge RES via REQ) 


(4.1 1 ) 
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‘.li expression (4.10) the stream structures ST-REQ and 
ST-TRIG circulate in the loop. However, since input and output 
of streams is asynchronous, and SI-REQ and ST-TRIG are not 
altered hy the loop, all the instantiations of inner loop will 
proceed simultaneously* Thus there is no substantial loss 
of asynchrony (only that the last instantiation of the inner 
loop will start after n units of time). The program in 
expression (4.10) uses the select operation on stream structures 
whoso execution time may be comparable to the execution time 
of case statement used in expression (4.11), when the number 
of conditions are less (say 2 or 3). However, with a large 
number of conditions execution rime of the case statement may 
be too high, and, it will also be cumbersome to write the 
predicates. The program in expression (4.10) does reflect the 
steps in the computation more clearly than the program in 
expression (4.11). 

4.7 Summary 

Wo have discussed stream structures which are useful 
in maintaining large and variable number of queues in the 
resource management. In fact stream structures can be used 
in any place where arrays of streams arc required. Furthermore 
stream structures require no new Id constructs and/or base 
language operators and they arc completely user-programmable. 
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PRO&R AIMER DEPUTED CONSTRUCTS 

In this chapter we propose a mechanism in Id by which 
new constructs can be defined. He call it programmer defined 
construct. Such a mechanism is useful in abstraction of 
operations and in defining one’s own language. In Section 4.2 
we discuss the syntax for the definition and the use of a 
programmer defined construct and the implementation details. 

We clarify certain points by discussing several examples in 
Section 4.3. finally, in Section 4.4 we discuss the limitations 
of our approach. 

5 • 1 A case for programmer defined constructs 

Design and implementation of large and complex software 
systems, their subsequent maintenance and modification, and 
proving correctness of such systems are facilitated if we 
reduce the amount of complexity that must be considered at 
any one time. Abstraction, whether it is of operations (events) 
or data, provides a way to separate !, what" from irrelevant 
"how" and thereby reduce the complexity. Data abstraction 
[ Gut 77, , LSAS77., .‘SWL77, >/LS76] has drawn much attention recently. 
However, we would also like to view operations in ah abstract 
way. To some extent, procedures in programming languages 
provide a way to the abstraction of operations. A procedure 
can be treated as a black box which performs a function and at 
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tlie time of its use one need not worry about "how” it does 
so . 

However, procedures are static in their nature, in the 
sense that they can operate only as a particular expression 
over different sets of parameter values. A more dynamic 
facility would bo one which specifies only the relationship 
among the expressions, the actual expressions being supplied 
at the time of its use tBac78]. 

As we mentioned in Chapter 1 that most of the existing 
programming languages are becoming bulky with the addition of 
newer and newer constructs to deal with specialized situations 
or extensions. Still, they remain inherently weak because 
they can not deal with situations for which they are not 
designed. This is due to the defects at the most basic level 
in their design. Their semantics is closely coupled to 
state transition and they divide the programs into expressions 
and statements. Whereas the expressions can be combined 
very easily to form higher level programs, it is difficult to 
do so with the statements. The result -isthat conventional 
languages are forced to have more rigid parts and less 
variable parts. A more rational approach would be to 
provide primitive building blocks alongwith a facility which 
is helpful in building complex and specialized structures 
using these primitive building blocks. Thus one should be 
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able to create his own language tailored to his needs 
[B a c 78] . 

Bearing the above two points in mind we propose a 
mechanism in Id which allows one to define his own constructs. 

We call them programmer defined c o nstruc ts (pdcs in short). 

Such mechanisms are provided in LISP E-IcC 62] and RED languages 
[Bac73 ? Bac78 ], GUI [LSAS77]and ALPHARD [SWL77 ] provide an 
abstract view of looping mechanisms. A dataflow language 
CAJOLE [ II0S78 3 , though in a very pre lirainary development 
stage, incorporates the idea of programmer defined constructs. 

5 . 2 Programmer defined constructs in Id 

A programmer defined construct in Id is composed of two 
parts - its definition and its use. The definition of a pdc 
specifies the relationship among the expressions (to be supplied 
later at the time of its use) using valid Id schemas. In 
defining the relationship, place of an expression is denoted 
by a variable enclosed in { } . We will call these variables 
exp - variables . Eor present discussion we assume that only 
three Id schemas ~ block expressions, conditional expressions, 
and loop expressions, can be used inside the definition of a 
pdc. The use of a pdc specifies the actual expression^ and the 
values of the arguments. These expressions are substituted in 
place of exp variables in the definition of a pdc. This 
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substitution, is performed at run time so the recursive 
definitions are allowed. The expression obtained after 
substitution is converted to a procedure value which is then 
applied to the actual argument values specified in the use of the 
pdc. This technique of defining constructs has some similaritie 
with the well known conditional assembly of macros used in low 
level languages t Str651. 

5.2.1 Definition of a. pdc ° 

The syntax for defining a pdc is given informally in 
expression (5.1)* 

construct [ {cplist }] |[ '^construct word5> !l {otbody x>} }f 

= (< 3 : definition of the construct ) 

(5.D 

; , j , <x , s> are metasymbols, tt ]] n denotes n 

occurances of the string enclosed in I II and for our purpose 
n > 1 . The formal syntax of construct definition is given in 
Figure 5.1. 

The string C " <s construct wordx>"{o£body 3>}]J n specifies 
how the pdc will be written when it is used in a program. The 
exp-variable { cplist } denotes a list of variables which will 
be supplied by an use of the pdc. We want to emphasize here 
that only valid Id expressions, and not Id statements, can be 
substituted in place of exp-variables i.e. variables enclosed 
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<x construct definitions ; s= construct [ <^xp-vari able 2 d 

<2: usage form (construct def s) 

<x exp-variables ;s={<s: identifiers} 

<Seusago forms : :=<x construct word-body s<s usage forms -0 

<3: construct word-body s 

<s construct word-bodys ;s=< 3 : construct word s<sexp-vari able s 
<sconstruct words 2; = "^identifiers" 

construct def s : :=<x valid extended bclu Id expression^ 

<2 valid extended bclu Id expression s ; := valid Id block, conditio- 
nal or loop expression or 
a construct use with 
<2 extended Id variables s 

<x extended Id variables 2>::= <xld variable 2> 'Q <2 exp-variable ^ 

<4 Id variables : := <s identifier s 

<x identifier s ; := string of English alphabets and special symbols 

excluding null string. 

Figure Syntax of the definition of a pdc. 



in { } . As an example, we give definition of a case expression 

using conditional expression in expression (5.2). 

construct [ {cplist} ] "case | "{pred 1 } ” ^ » { tody 1 } 

"{pred 2 > " =>" { tody 2 } 

= (if {pred 1} then {body 1 } 
elseif { pred 2 } th en {tody 2} 
else ) (5.2) 

Expression (5.2) does not bring out all the points which 
are important, however, it is only intended to give a flavour 
of syntax. Other points will be made clearer in later sections. 

5.2.2 Use of a pdc ; 

The syntax for the use of a pdc can be explained 
informally by expression (5.2). 

t ^list ■£> Iff " « construct word x>" csexp »N n 

using [<x argument list » ] (5.3) 

Formal synatx is given in Figure 5.2. 'exp' denotes any 
valid Id expression or a list of expressions. 'list* specifies 
the variables used in these expressions. Actual values of 
these variables should be supplied from outside. We have 
introduced a new reserved word, using, . The list following 
using i.e. 'argument list' specifies the actual values for 
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<x construct uso >o ;:=[<s: list»]<x use form » 

usin g [<x argument list2>] 

<2 list s> ; s= <£ identifier <2 list » $<£ identifiers 
<suse forms> s := <s construct word usexxs uso form s ]J 

<2: construct word uses 

< 3 construct word use £> s : = <2: construct wordsxsrvalid Id exp+const:g> 
<svalid Id expression* const 2 > s:=<x valid Id expression s> [[ 

<3: construct use » 

^argument list x> ;:=<s:valid Id expression^ ,<i argument list s> 

H<£ valid Id expression s> 

^construct word S> : := "<2 identifiers 11 

<xvalid Id expression^ ::= any valid Id expression 

<£identificr s> s.= string of English alphabets and special symbols 

excluding null string 

Figure 5*2 Syntax of the use of a pdc. 
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variaolos listed in 'list 1 . The correspondence is by position 
(easiest , though other formulations can be specified). 
'Argument list' may contain valid Id expressions as the values 
for the variables listed in 'list', in -which case expressions 
are first evaluated and then the evaluated values are passed* 
using also specifies the scope of the pdc . 

Expression (5.4) shows the use of the pdc defined 
in expression (5.2). 

z ( C x,y ,a,b,i,n ] "case |" i< n"=>" x+2*a 

" I” i= n t, =>" y+2*b*a 

using fe,y,e,f f i,1 0 ] ) (5.4) 

Here we would like to point out the difference between 
x in 'list 1 and x in 'argument list*, x in 'list' denotes 
a variable which will be used inside the pdc , whereas, x in 
'argument list' denotes the variable (i.e., the line in base 
language graph) outside the pdc. us ing specifies an inter- 
connection between them. The facility of using can be made 
general enough so that it can be used to avoid writing 
statements in many cases. 

5.2.3 Implementation of a pdc ; 

Like a procedure va-ue, the definition of a pdc is 
translated as constant function which produces a new type of 
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'value called 'pdc'. The value of the type pdc has the 
following internal representation: 

< name : pdc nane , 

usage form: the string enclosed in II 1 in expression 
(5.1 ) 

definition: definition of the pdc > 

pdc name is obtained by concatenating all the construct 
words. The translation of expression (5.2) is shown in 
Figure 5.5. 

The use of a pdc is translated as a function evalc . The 
inputs to the function evalc are: 

1 . pdc definition value. 

2. A structure containing 'list' and the actual 
expressions in the form of strings. For future 
reference this structure will be called expvalue . 

3 The actual values of arguments as given in 
1 argument list 1 . 

The function evalc evaluates the pdc and its outputs 
are the outputs of the pdc expression. Figure 5.4 shows the 
translation of expression ( 5 . 4 ). 

The function evalc is not implemented as a primitive 
operator. It is composed of two operators - substitute, and 
apply. Figure 5.5 shows the internal structure of evalc and 
one may refer to it to understand the functions of two 
operators, which are discussed below. 



89 



Cstrigg er 

V 

< names case | 

, 1 ' " ' - *1 

= > I = > 

usage; "case 

| " {predl} " => " {bodyl > 

» |" {prod 2} " = >" { body 2 > 

definition; 

(if { predl} then {bodyl } 


elseif {pred2 >thon {body2 } 


else ) > 


* value of type pdc 

(pdc definition value) 

T 


Figure 5.3 Translation of the definition of 
pdc of expression (5.2). 
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a . sub st it xr to ; 

It performs two functions - it substitutes the actual 
expressions in place of exp-variables and then it creates a 
new procedure value using substituted definition. If the data 
structure of Id expressions is represented in the form of 
structure or string values then no new operator except a coercior 
function from structure or string to procedure is required. The 
created procedure value is passed to tho apply operator. The 
actual expressions are obtained from structure expvaluo. The 
correspondence between acttial expressions and exp-variables 
is decided using usage part of pdc definition value and is 
by position i.o. expvalue.1 corresponds to {cplist > and so on. 
Name of the created procedure value is the first construct 
word and formal parameter list of the procedure value is the 
actual list corresponding to { cplist >. To allow for recursive 
definition of a pdc, pdc definition value is passed to the 
procedure value as a "free zed" argument. 

u.c.s^.i - - input: port 1 (pdc definition value) = c^. 

port 2 = expvaluo 

out put tz « cr e at e pr o c ( sub s t ( c , expvaluo ) ) >, 

subst performs string substitution and it can be 
expressed as an Id procedure. However, ere ate pro c converts 
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the substituted definition to a procedure value and cannot 
be expressed in Id. The procedure value passed to apply 
operator at the execution time of expression (5.4) is given 
by q in expression (5.5). 

P •*- procedure case (construct, x,y,a,b,i,n) 

(if i< n then x+2*a 
elseif i = n then y+2*b*a 
else ) | 

1 * compose (p,< case | =>]=> > ) (5.5) 

b . apply : 

It takes the procedure value which is passed to it by 
the operator substitute and applies it to the actual arguments. 
The results are passed to the program segment where construct 
is used. This operator is discussed in some detail in 
Section 2.5. 

5.3 Some examples 

In this section we will discuss some examples of pdcs 
to illustrate some of the points relevant to their definition 
and their use. 

a . A while loop : 

Expression (5.6) gives recursive definition of a pdc 
which is equivalent to the whil e loop in Id. Expression 
(5.7) shows its use. 
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construct [{ cplist) ] "while" { predicate} "do" 

{ body} 

= (if { predicate } then [{ cplist }] 

'’while" {predicate }"do" 
{body} 
usin^g [{body}] 
else {cplist} ) (5*6) 


[sum, x,i,n ] "while" i<_n "do" 

sum +x,x,i+1 ,n 

using [sumo, xo,1,10 ] (5.7) 

Values returned by expression (5*7) are the final values 
of the expressions sum+x, x, i+1 , n. This example brings out 
a restriction i.e. use of any recursively defined pdc should 
return the values for all the variables specified in its ’list 1 . 

b . A for-while loop : 

Wo implement a for-while loop using the pdc mechanism 
and the for each- while loop. The implementation is based on 
the translation of for-while loop into a for each - while loop 
as discussed in Chapter 3. The definition of the construct 
is given in expression (5.8). 
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const ruct r {cplist} ] "for"{ v a r> "from” {lower limit} 

"to" {upper limit Fly" { stop} 

"while" {prod.} ''do" 

{body } 

"return" { explist } 

= ( ’local 1 . {explist} , S * ^(initial {cplist }-«-{eplist } 

for each Wax )in I 
while {-pred}A{var }^ e do 
new ({ cplist } ) *■{ tody} 
retum { expli st } , all true ) 5 

S*- cons ( true , S' ) °, 

& * 

1+ ( initial 3 -f- {lower limit } 
for each s in S do - • 

if j<{ upper limit }then new 3 •*- 3 + {step } 5 

3 ' +- 3 

els e new 3 <-e 7 
3 * •*- e 


return all 3 1 ) \ 

return ‘local* • l explist } ) ( 5 . 8 ) 


The use of the above construct is shown in expression 


(5.9) 
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[ sum, p,q,r,n,a ] "for" i "from" p "to" q "by" r 

"while" sum < n "do" 

sum+i-'a,p,q,r ,n,a 
"return" 3* sum 

using. [ sumo, 1,10,2,s,b] (5.9) 

¥e used the reserved word now in a rather different 
manner in expression (5.3). If we assume that{ cplist}^ a,h,c 
then at the time of substitution new ( { cplist} ) will be 
converted to new a, new b, new c# lie have also introduced 
a new way of generating variable names. 'local*. { explist} 
means that string 'local' is concatenated with all the strings 
occuring in {explist} and now variable names are formed. As 
an example, if {explist} = x,x+y then 

1 local 1 . {explist }= localx,localx+y . 
localx+y is the name of a variable. The need to do this stems 
from the single assignment property of Id. 

c . A for loop that returns streams ; 

Expression (5.10) gives the definition of a pdc 
which is equivalent to the Id for loop with return all 
construct. Expression (5.11) shows how it cah be used in 


a program 
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instruc t [{cplist } ] "for"{v a r } "from" {lower 'limit) 

"to" { upper limit) "do" 

{ body ) 

"return" { explist 1 )"all" {explist 2} 

= ( initial) cplist )♦ {cplist) ; { var }-«-{ lower limit ) 
while {Tar )^. {upper limit ) do 
new( { cplist })-«-{ body 
new {var) «-{ var } + 1 
return { explist 1 ) , all ({explist 2))) 

(5J0) 


[x,y,p,n] "for" i "from" p "to" n "do" 

f(x,y,i), f'(x,y,i), p,n 
"return" x,y "all” g(x,y,i) ,g* (x,y,i) 
using; [xo,yo,1,10 ] (5.11) 

In this example we usod a while loop to define a for 
loop. In expression (5.10) the use of all is similar to the 
use of new in expression (5.8). 

d. A sequential loop construct ; 

We now implement a sequential for each loop construct 
as a pdc. Our implementation is based on translation given in 
Chapter 3 (expression ( 3 . 5 )). The definition of the pdc is 
given in expression ( 5 . 12 ) and its uso in expression ( 5 . 13 ). 
This example brings out some of the limitations of our approach. 
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construct [{cplist } ] ’’for each" { varl } "in" {streaml 

{ var 2 } i!in ,! {stream 2 }"do" 
{ body } 

"return” { explist } 

= (I ’ ,J’ **- (for e ach i in {streaml } do 

I'jJ’-t- ( for each 3 in {strenn 2 "j^p 
return all i, all 3 ) 
return all I ’ , all J ’ ) 
return ( initial { cplist }<- {cplist} 

for each. { varl } in I’?{var2}in -J’ do 
new ( { cplist} ) «-{body } 
return { explist} )) ( 5 . 12 ) 

[x,y , 1 , J ] "for each" i "in" I %" 3 "in" J "do" 

f (x,i, 3 ) , f(y,i,j) 

"return" x,y 

using [ xo , y o , I , J ] (5.13) 

Since the values of the streams I and J should be 
supplied from outside, they occur in the ’list’ in expression 
(5.13). At the time of substitution^ cplist} = x,y,I»J and 
thus statement new ( ( cplist} )-*• { body }will be translated as 

new x , new y , new I ? new J { bo dy } • 

This will result in circulation of streams I and J in the 
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second loop of expression (5.12). Circulation of streams is 
to be avoided for the obvious reasons of efficiency. In fact 
in this ease second loop never uses the streams I and J. in 
optimising compiler may detect this fact and treat I and J as 
dead variables. 

Away to avoid sudi a circulation of streams would be 
to define a deletion operation on { cplist } . If we denote 
the deletion operation by - then we can write 

new ( {cplist}' - {strcaml } - {stream2 }) -(-{body } 

which, when translated at the substitution time, would result 
in 

new x, new y -*- {body}. 

Then one can also think of defining a complementary operation 
addition on { cplist } . 

5.4 Limitations of our approach 

We pointed out a limitation of our approach in 
example (d) in Section 5.3 and suggested a solution. The 
limitation arose from our need to distinguish between 
circulating and uncirculating variables in a loop expression 
for the reasons of efficiency. Sometimes a programmer may 
want to circulate a stream to obtain desired results. Our 
proposed solution is neither elegant nor general enough. 
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It also increases the complexity of 'subst* in the implemen- 
tation. A general solution to distinguish circulating variables 
from uncirculating variables will require a complete analysis 
of the program. 

Second limitation or restriction is pointed out in 
example (a) in Section 5.3>i *e. a recursively defined pdc 
should return values for all the variables in 'list'. 

Finally wo would like to point out that our approach 
is not dynamic enough. Consider the definition of a case 
expression as given in expression (5.2). This expression can 
deal with only two cases. We have to define separate case 
expressions to deal with three cases, four cases and so on. 

A general case expression dealing with any number of cases 
cannot be defined in our model because a pdc is ultimately 
converted to a procedure and thus cannot model dynamicness 
in its definition itself. Conversion of a pdc to a procedure 
also reduces the interaction between the use of the pdc and 
the program where it is being used. 

5.5 .Summary 

In this chapter we have discussed the definition, the 


use, and the implementation of programmer defined constructs 
in Id. Programmer defined constructs are useful in abstraction 



of operations and in defining one's own language. The 
definition of a pdc specifies the relationship among 
expressions in terms of Id schemas and dummy expressions. 
The actual expressions are supplied hy the use of a pdc. 
To bring out certain important points and limitations 
of our approach we have discussed several examples. 



CHAPTER 6 


CONCLUSIONS 


In this thesis we have proposed certain extensions to 
the high level data flow language Id so that its basic 
mechanisms can be fully exploited. It is evident from the 
discussions in Chapter 3 and 4 that some of these extensions, 
can be incorporated without any major alteration in the set 
of base language operators. An alternate translation of the 
fon loop and the for each - while loop as discussed in Chapter 3, 
enables us to incorporate sequential and mixed looping 
constructs and to enumerate the elements of a pdt in a 
controlled fashion. Similarly in Chapter 4 a slight modification 
of monitors enabled us to exploit the stream structures in the 
resource management problems. This points to the fact that 
the basic mechanisms in Id are powerful enough and their full 
potential is yet to be realized . In Chapter 5 programmer 
defined constructs were proposed as an addition to the basic 
mechanisms in Id. In fact the pdcs can be used to implement 
most of the constructs discussed in Chapter 3 and thus 
effectively reduce the size of the language. 

Many ideas from Id and this thesis can also be extended 
to the conventional languages. The structure of the looping 
constructs in Id explicitly specifies the initialization 



of the loop variables, and, an Id loop can terminate only 
when the associated predicate turns false. Such a structure 
of loops in a conventional language will facilitate program 
verification. An equivalent of parallel for each - while 
loop construct alongwith the generators will be able to 
model nearly all looping constructs in a conventional 
programming language. Recent languages such as A1PHARD have 
adopted such a view of loop constructs. 

Another idea which can be extended to conventional 
programming languages is that of programmer defined constructs 
type. Using the conventions of Chapter 5, below we briefly 
outline how pdcs can be incorporated in the conventional 
languages : 

Whenever a construct definition is encountered, it is 
entered in a structure, say environment . The user (always) 
specifies the name of the environment he will bo using during 
the execution of his program. Initially environment may 
be an empty structure. Whenever a construct use is encountered 
it is translated into two statements? 

1 . a call to a system procedure evalc with the name 
of the construct and a structure containing actual 
expressions , 

2. a call to the procedure, whose name is the first 
construct word, with the arguments specified in the 
argument list of the construct use. 
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The system procedure ovale substitutes the actual 
expressions in the construct definition, creates a procedure 
from the substituted definition, and then calls the 
compiler to translate the created procedure, a dynamic 
linking and loading facility will make the procedure available 
to the program, for incorporation of the mechanism in the 
languages which do not view the procedures as functions, the 
{cplist} needs to be extended to include the variables whoso 
values are being returned by the construct. The arguments 
are transferred using 'call by value'. 

During' the course of this work we recognized many areas 
which are still unexplored or partially explored. Our 
discussion on pdcs is certainly not the last word on the 
subject. There are certain limitations in the proposed 
approach and it would bo worthwhile to investigate how these 
limitations can be removed from the present frame work# 

Another area of interest is the specification of a minimal 
set of Id constructs which alongwith the facility of pdcs 
are powerful enough to model any programming problem. In 
specifying such a minimal set, the efficiency consideration 
should not be unduly compromised. Also the constructs in 
the minimal set should not be at such a primitive level that 
one has to deal with the base language. 
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Be cent Turing lecture "by J# Backus tBac78] has 
"brought functional forms of programming languages into 
vogue. At this stage we speculate that if the unravelling 
interpreter can be made to execute functional progi'ams 
efficiently, then the resulting system will be able to do 
away with most of the objections against conventional systems 
(both software and hardware) and can emerge as a powerful 
next generation system. 
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